High Efficiency Video Coding (HEVC) is a new coding standard that has been developed in recent years. In the High Efficiency Video Coding (HEVC) system, the fixed-size macroblock of H.264/AVC is replaced by a flexible block, named coding unit (CU). Pixels in the CU share the same coding parameters to improve coding efficiency. A CU may begin with a largest CU (LCU), which is also referred as coded tree unit (CTU) in HEVC. In addition to the concept of coding unit, the concept of prediction unit (PU) is also introduced in HEVC. Once the splitting of CU hierarchical tree is done, each leaf CU is further split into one or more prediction units (PUs) according to prediction type and PU partition.
Along with the High Efficiency Video Coding (HEVC) standard development, the development of extensions of HEVC has also started. The HEVC extensions include screen content coding (SCC). Due to specific characteristics of screen contents, coding tools have been developed and demonstrate significant gains in coding efficiency. Among them, the colour index coding (a.k.a. major colour based coding) techniques represent block of pixels using indices to the palette (major colours), and encode the palette and the indices by exploiting spatial redundancy. While the total number of possible colour combinations is huge, the number of colours in an area of picture is usually very limited for typical screen contents. Therefore, the colour index coding becomes very effective for screen content materials. Related key colour index coding techniques are briefly reviewed as follows.
During the Course of Screen Content Coding (SCC) development, various video coding tools have been described, including the “Intra picture block copy” (IntraBC) technique. The IntraBC technique was first disclosed in JCTVC-M0350 (Budagavi et al., AHG8: Video coding using Intra motion compensation, Joint Collaborative Team on Video Coding (JCT-VC) of ITU-T SG16 WP3 and ISO/IEC JTC 1/SC 29/WG11 13th Meeting: Incheon, KR, 18-26 Apr. 2013, Document: JCTVC-M0350). An example according to JCTVC-M0350 is shown in FIG. 1, where a current coding unit (CU, 110) is coded using Intra MC (motion compensation). The Intra MC is also named as Intra Block Copy (IntraBC). The prediction block (120) is located from the current CU and a displacement vector (112). In this example, the search area is limited to the current CTU (coding tree unit), the left CTU and the left-left CTU. The prediction block is obtained from the already reconstructed region. Then, the displacement vector, also named motion vector (MV) or block vector (BV), and residual for the current CU are coded. It is well known that the HEVC adopts CTU and CU block structure as basic units for coding video data. Each picture is divided into CTUs and each CTU is reclusively divided into CUs. During prediction phase, each CU may be divided into multiple blocks, named prediction units (PUs) for performing prediction process.
In JCTVC-M0350, the IntraBC is different from the motion compensation used for Inter prediction in at least the following areas:                BVs are restricted to be 1-D for IntraBC (i.e., either horizontal or vertical) while Inter prediction uses 2-D motion estimation.        Binarization is fixed length for IntraBC while Inter prediction uses exponential-Golomb.        IntraBC introduces a new syntax element to signal whether the BV is horizontal or vertical.        
Based on JCTVC-M0350, some modifications are disclosed by Pang, et al., in Non-RCE3: Intra Motion Compensation with 2-D MVs, Joint Collaborative Team on Video Coding (JCT-VC) of ITU-T SG 16 WP 3 and ISO/IEC JTC 1/SC 29/WG 11, 14th Meeting: Vienna, AT, 25 Jul.-2 Aug. 2013, Document: JCTVC-N0256 (hereinafter JCTVC-N0256). Firstly, the IntraBC is extended to support 2-D MVs, so that both vertical and horizontal MV components can be non-zero at the same time. This provides more flexibility to IntraBC than the original approach, where the MV is restricted to be strictly horizontal or vertical.
In JCTVC-R0309 (Pang, et al., “Non-SCCE1: Combination of JCTVC-R0185 and JCTVC-R0203”, JCTVC-R0309, Joint Collaborative Team on Video Coding (JCT-VC) of ITU-T SG 16 WP 3 and ISO/IEC JTC 1/SC 29/WG 11, 18th Meeting: Sapporo, J P, July 2014), the neighbouring BVs and coded BVs are used as BV predictor (BVP). The BV predictor is derived similar to the AMVP (advanced motion vector prediction) scheme in HEVC. The predictor candidate list is constructed by first accessing in order the spatial neighbouring blocks a1 (220) and b1 (230) of a current block (210) as shown in FIG. 2. If any of the spatial neighbours doesn't have a block vector, the last two coded BVs are used as substitute block vectors to fill the block vector candidate list so that the list contain two different entries. The substitute block vectors are initialized with (−2*CU_width, 0) and (−CU_width, 0), where CU_width is the width of the CU. To avoid the line buffer, the above BV out of current CTU is considered unavailable. The last two coded BVs are reset to (0, 0) for each CTU to prevent the data dependency.
In HEVC, Merge candidates are derived from spatial/temporal neighbour blocks for the current coded block in an Inter coded slice. A merge_flag is used to signal whether the current block is merged into one of its candidates. If yes, another index is used to signal which of the candidates is used for Merge mode. For example, if candidate block a1 in FIG. 2 is signalled as the candidate to be used, then the current block will share the same motion vector and reference picture as those in block a1.
If any Merge candidate is not available (e.g. non-existing or not coded in Inter mode), additional candidates are inserted into the candidate list. If the Merge candidate list is still not full after inserting the additional candidates, zero motion vector with reference index (i.e., refldx) equal to 0 will be used to fill all the empty candidates.
Two types of additional candidates can be inserted:                1. Combined bi-predictive Merge candidate (candidate type 1)        2. Zero vector Merge/AMVP candidate (candidate type 2)        
The type-2 additional candidates are inserted after the type-1 additional candidates.
For the type-1 candidate, combined bi-predictive Merge candidates are generated by combining original Merge candidates. In particular, two original candidates, which have mvL0 (the motion vector in list 0) and refldxL0 (the reference picture index in list 0), or mvL1 (the motion vector in list 1) and refIdxL1 (the reference picture index in list 1), are used to generate bi-predictive Merge candidates.
For the type-2 candidate, zero-vector Merge/AMVP candidates are generated by combining zero vectors and reference index which can be referred. If zero-vector candidates are not duplicated, it is added to Merge/AMVP candidate set.
In SCM-2.0 (Joshi, et al., Screen content coding test model 2 (SCM 2), Joint Collaborative Team on Video Coding (JCT-VC) of ITU-T SG 16 WP 3 and ISO/IEC JTC 1/SC 29/WG 11, 18th Meeting: Sapporo, JP, 30 Jun.-9 Jul. 2014, Document: JCTVC-R1014), coding of block vector difference is modified to use one context-coded bin for coding each vector component. Methods to further improve the coding efficiency and to enable unification of BVD and MVD coding have also been disclosed in the literature.
In SCM-3.0 (Joshi, et al., Screen content coding test model 3 (SCM 3), Joint Collaborative Team on Video Coding (JCT-VC) of ITU-T SG 16 WP 3 and ISO/IEC JTC 1/SC 29/WG 11, 19th Meeting: Strasbourg, FR, 17-24 Oct. 2014, Document: JCTVC-51014), a ladder shaped IntraBC search range constraint is adopted, as shown in FIG. 3, where the blocks with cross-lined background indicate the ladder shape IntraBC search range and block 310 corresponds to the current CTU. For an IntraBC block in current CTU, the available search area is constrained to the CTUs with dotted background and the reconstructed blocks in the current CTU.